함정에 빠지기 쉬운 애자일 프랙티스 피해가기

애자일에 대해 수많은 오해가 있지만, 그 중에 또 하나 독특한 것은 애자일 프랙티스에 대한 난이도 이해가 거꾸로 되어 있는 경우가 많다는 것이다. 그래서 몇몇 함정을 피해가기 위한 짤막한 조언들을 써본다. 이유나 근거는 생략한다.

1. TDD는 바로 시작해도 좋다. 하지만 TDD에 충분히 익숙해지기 전에는 regression test 용도로 테스트를 활용하지 말라.
2. 새로운 팀원이 왔을 때 소스코드를 체크아웃 받고 나서 로컬 머신에서 5분 이내에 주요 기능을 실행해볼 수 있고, 테스트 스위트를 돌려볼 수 있고(테스트 스위트를 돌리는 전체 시간이 아니라 테스트 스위트를 돌리는 명령을 실행하기까지의 시간이 5분 이내), 아주 손쉽게 테스트 케이스 중에서 특정 테스트 메서드 하나만 돌려볼 수 있는 상황을 만들기 전까지는 jenkins 등의 자동화 빌드를 사용하지 말라.
3. 포스트잇으로 그럭저럭 프로젝트 관리를 할 수 있다고 느끼기 전까지는 이슈 트래커, 칸반보드 등을 사용하지 말라.
4. 페어프로그래밍은 어렵다. 처음 할 때는 30분 이내로 하는 게 좋다.
5. 커밋/푸시/디플로이 절차가 복잡할수록 고객은 더 오랫동안 버그를 경험한다.
6. 스토리 포인트는 가능한 한 짧은 시간에 대강 추정할 것. 아니, 추정하지 마.
7. 스토리 포인트는 일정과 연관 짓지 말 것. 
8. 이슈 트래커에서 측정할 수 있는 여러 가지 숫자는 모두 프로젝트의 진척도를 평가하는데 중요하지 않다. 
9. 일정과 스펙은 둘 중에 하나만 고를 수 있다. 하지만 고객, 혹은 Product Owner에게 둘 중에 하나를 선택하라고 요구하진 말라. 
10. 리팩토링의 목적은 다음 프로젝트가 아니라 이번 프로젝트를 빨리 끝내기 위한 것이다.
11. 활발한 커뮤니케이션은 개발자에게 자주 말을 거는 것이 아니라 개발자에게 빨리 대답해주는 것이다.
12. 회고에 많은 시간을 썼는데 다음 주기에 똑같이 일하고 있다면 회고한 시간은 순수한 낭비다. 
13. 애자일에 완벽하게 통달했다고 자부하기 전까지 스크럼은 하지 말라.

쉽게 요약하면, 하지마 하지마 하지마 정도가 되겠다...

원래 애자일은 체계적이고 크고 아름다운 방법론이 아니고 대충 막 개발하는 난장판식 개발에 더 가깝다. 난장판으로 놀면 이웃에 피해를 주니까 얌전하게 놀자는 게 아니라 맘 내키는대로 놀되 방음처리 잘해서 이웃 시끄럽게 하지 말고, 다 놀고 나서 깨끗이 잘 치우자는 게 애자일이다.

그러니까 대충 좀 해라 대충 좀.